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(54) Email using queues in non-presistent memory 

(57) An E-mail processing system that preferably op- 
erates solely within nonpersistent storage such as ran- 
dom access memory. Queues of e-mails are formed with- 
in the random access memory, where each queue in- 
cludes a pointer to personalized information about the e- 
mail, directed to a specific domain. In order to send the 
e-mail, a channel is opened to the domain, and while 
open, e-mails within the queue are sent. A special recov- 
ery agent periodically takes snapshots of the state of 
processing within the system. Since the processing is 
occurring within nonpersistent storage, a failure within 
the system can be recovered by using the snapshots to 
recover where each e-mail is processing, in one aspect, 
the feed rate to the other e-mail servers is adjusted based 
on the rate of those e-mail servers. Also, the system asyn- 
chronously looks up information such as DNS information 
while it is processing information for other e-mails. 
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Description 

Cross Reference To Related Applications 

[0001] This application claims the benefit of U.S. Pro- 
visional Application No. 60/449,301, filed on February 
20, 2003, the contents of which are herewith incorporated 
by reference. 

Background 

[0002] E-mail is a well-established process of sending 
a text message from a sender to a recipient. The process 
of conventional e-mail is defined by a number of different 
interacting protocols and servers. 
[0003] In conventional e-mail, a personal computer 
100 runs an e-mail client 102. Well-known e-mail clients 
include Microsoft outlook and Outlook express. The e- 
mail client may be a standalone client, or may be a mod- 
ified e-mail client running within a web page such as "Hot- 
mail". The e-mail client lists the messages in the user's 
mailbox by headers, and allows the user to select and 
read the e-mail that is associated with that header. An e- 
mail client also allows creation of new messages and 
sending of the new messages. 

[0004] The e-mail client communicates with an e-mail 
server 120 at the user's local Internet Service provider, 
here shown as "domain" 99, in order to send and receive 
messages over the Internet 1 1 0 or more generally over 
any network connection. A domain can include a single 
mail cluster, e.g., all of hotmail.com, or can include mul- 
tiple mail clusters that are somehow associated. 
[0005] The server receives e-mail messages from a 
client 1 02, and forms a list of those messages. The server 
120 typically includes a processor or computer of some 
type, running the special email programs that are de- 
scribed herein. 

[0006] The mechanics of the e-mail system operate by 
using three different protocols, known as SMTP, POP3 
and IMAP. The SMTP server listens on port 25 to receive 
incoming emails. 

The POP3 server 140 handles delivery of local messages 
to the local mailboxes, such as 145. The mailbox is really 
a queue that is formed to provide the message an email 
client, when that client logs in to the POP3 server 140 at 
the domain 99. 

[0007] Sending emails is handled differently than re- 
ceiving emails. In order to send an e-mail, the e-mail client 
102 interacts with the SMTP server 130 at the domain 
99. If the message is intended for another mailbox within 
the same domain, then the SMTP server 130 sends the 
message to the local POP3 server 140. If the message 
is intended for another domain, the SMTP server com- 
municates with a domain name server or DNS 135. The 
DNS stores a database, which is updated from the inter- 
net, that stores the IP address for all domains. The DNS 
provides the IP address to the SMTP server 130. 
[0008] The messages are stored on the hard drive 1 31 



of the SMTP server 130. Software called a "picker" often 
operates to streamline the operations. The picker looks 
at messages stored on the SMTP server's hard drive 
131 , and carries out the mechanics of analyzing the mes- 
5 sage headers for destination, communicating with the 
DNS, and looking for an available port for the SMTP serv- 
er on the destination domain. 

[0009] Once these operations are completed, the 
SMTP server 130 sends the message using the IP ad- 

10 dress that it obtained from the DNS server 1 35 to another 
SMTP server 150 at the destination domain 149. The 
SMTP server 1 30 communicates with the corresponding 
SMTP server 155 at domain 149. The message is trans- 
ferred to the SMTP server 155 at domain 149. Since 

15 SMTP server 1 55 recognizes that the message is for a 
local mailbox, it provides the message to its local POP3 
server 160 which queues the message to a local mailbox 
165. 

[0010] Sending email often uses an open-source pro- 
20 gram known as sendmail™ which also includes many 
additional capabilities, including the ability to queue mes- 
sages which cannot be sent immediately. 
[0011] The receiving of emails uses POP3 server. The 
POP3 server maintains a collection of text files, one for 
25 each e-mail that has been sent or received. Each time a 
new e-mail is received, it adds that e-mail to its recipient 
file, or mailbox. The e-mail client 1 02 communicates with 
the POP3 server 140 at the local domain 99. The POP3 
server provides the e-mail client 102 with contents of its 
30 mailbox, and then deletes the messages. 

[0012] An IMAP server may be used in addition to or 
in place of POP3. IMAP allows the e-mail into folders 
which stay on the server. 

[0013] For a large e-mail server, there may be many 
35 pickers operating at once, e.g. 50 to 100 pickers. Each 
0 f these pickers are obtaining information from the SMTP 
server's hard drive 131 , moving messages one at a time 
from the hard drive. 

40 Summary 

[0014] It has been noticed that throughput limitations 
often occur in conventional e-mail systems of the type 
noted above. Certain limitations may be caused by the 
45 need to access files that are on the hard drive of the 
SMTP server. 

[0015] The present system describes a messaging 
system that may operate in this conventional e-mail en- 
vironment, but which may reduce delays caused by the 

50 operations. The inventor recognized that the operations 
on the hard drive of the SMTP server can burden the 
server and can also cause limits in throughput. According 
to an embodiment, the messaging system may store the 
mail in memory queues and memory queue maps that 

55 are formed within non-persistent, e.g., random access 
memory. A message transfer agent formats the messag- 
es and addresses, and organizes them to be sent from 
the memory. Therefore, for example, this system allows 
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opening a pipe to a specific domain such as Hotmail, and 
then sending through as many messages as possible. 
[0016] In an embodiment, e-mail messages are read 
directly from the database into memory and delivered to 
mailboxes or a host, without writing those e-mails back 
to persistent storage as part of the e-mail handling rou- 
tine. 

[0017] One aspect describes a message wrapper util- 
ity that divides the message into personalized and non- 
personalized parts. 

[0018] Another aspect describes a crash prevention 
agent that stores the information within the non-persist- 
ent memory at intervals. The state of the application 
processing is thus saved to disk, in a very efficient way. 
This facilitates recovery in the event of a crash, while 
minimizing the amount of the information which is actually 
saved to disk. 

Brief description of the drawings 

[0019] These and other aspects will now be described 
in detail with reference to the accompanying drawings, 
wherein. 

[0020] Figure 1 shows a diagram of e-mail flow; 
[0021] Figure 2 shows a diagram of the queues that 
are formed according to the present system; 
[0022] Figure 3 shows a flowchart of creating and han- 
dling the queues; 

[0023] Figure 4 shows a flowchart of processing the 
messages within the queues; 

[0024] Figure 5 shows a flowchart of one aspect of the 
load balancing; 

[0025] Figure 6 shows a block diagram of the queues 
and agents handling the queues; and 
[0026] Figure 7 shows the different functional ele- 
ments that make up the operating program. 

Detailed Description 

[0027] The present system describes an improved e- 
mail handling and transferring system. 
[0028] Initially, the description given herein is a de- 
scription of software modules which run on a general- 
purpose computer, such as a workstation type computer 
or a computer based on the x86 architecture. However, 
it should be understood that the description is given here- 
in could operate as hardware, for example based on the 
dedicated circuitry, or in FPGA components, with the 
functions being defined in hardware definition language. 
While the description given herein is of software, the in- 
ventors intend this description to similarly cover hardware 
devices which operate in comparable ways to that de- 
scribed herein. 

[0029] Figure 2 illustrates the formation and use of a 
message queue map. The message queue map is pref- 
erably formed in non persistent storage, e.g., random 
access memory running within a mail server, e.g., the 
server performing the SMTP function. In a preferred em- 



bodiment, the entire mail processing operation occurs in 
non-persistent memory of this type. 
[0030] Prior systems have taught away from using 
non-persistent memory for the email processing. In fact, 

5 the use of non-persistent memory could cause significant 
problems when and if the system crashes during opera- 
tion. The present system, however, teaches a way to 
avoid loss of functionality during a crash, by storing in- 
formation about which emails have been processed, and 

10 the state of processing of these emails. An aspect de- 
scribes a very efficient way to save that state. 
[0031] The queue map which is shown in figure 2 has 
a number of message queues shown respectively as 200, 
202 and 204. 

15 Each of the message queues is defined based on various 
variables that may include domain name, systems user 
(in case of virtual servers). In simplest version of a queue, 
it is associated with a specific domain. For example, mes- 
sage queue 200 is associated with domain 210 which is 

20 Hotmail.com. Message queue 204, intended for ya- 
hoo.com (domain 214), includes two different data nodes 
252, 254, which are each intended for delivery to domain 
yahoo.com. Each data node represents personalized in- 
formation about the e-mail to be sent. 

25 [0032] A new message 220 is also shown. As part of 
the operation, this new message needs to be added into 
the existing queue map. An input handler shown as 225 
may operate as shown in the flowchart of Figure 3. At 
300, the process receives the new message 220. The 

30 input handler operates, at 305, to create a data node 230 
as a digest representing the message. A data node in 
this embodiment is an object that represents one mes- 
sage. The data node includes information about the mes- 
sage being sent; and may include the recipient, sender, 

35 data about the email, domain, a unique session identifier, 
visit count, and other information for Quality of Service 
("QoS") guarantees and routing specifics. Note that the 
nodes are not the emails themselves - rather they are 
just pointers to the emails as stored in memory. 

40 [0033] The data node is analyzed to determine the ap- 
propriate queue (function of domain and miscellaneous 
variables) at 310. Step 315 determines if the message 
can be appended to an existing queue. If so, then the 
data node is appended to the existing queue at 320. 

45 [0034] For example, here the new message 220 is in- 
tended for the domain 210 of Hotmail.com. Therefore, 
the data node 230 is appended to the end of the existing 
queue 200. 

[0035] In the alternative, if the node cannot be put into 
50 an existing queue at 315, then a new queue is created 
at 325, and the data node 230 is appended to the newly 
created queue at 330. In this way, multiple queues are 
formed, each relating to nodes representing messages 
with similar routing strategies. Multiple queues may be 
55 provided for each queue variable if the existing queue 
has more than a maximum number of messages. 
[0036] Since each queue represents messages that 
will require the same processing strategy such as deliv- 
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ery to the same domain, the entire queue of messages 
can be sent at once, thereby streamlining the sending 
process. 

[0037] A command set, shown here as the output han- 
dler 240, can operate on the messages and queues ac- 
cording to the flowchart of Figure 4. Each data node rep- 
resents a particular message. The output handler proc- 
esses the data node in order to send the mail to the in- 
tended recipient. The output handler 240 is shown as 
being a single process, but multiple processes may be 
operated at once, with, for example, each process han- 
dling a single queue at any one time or using a pipelined 
or multi-threaded system. 

[0038] The process starts at 400, where the output 
handler looks for the next queue to process. This may 
be done in round-robin fashion, where each queue is 
assigned a number (n) for example, and the system sim- 
ply looks for n+1 queue, where a maximum n of queues 
can exist. An alternative system is that the output handler 
always handles the queue with the greatest number of 
message nodes therein. In this example, queues are sort- 
ed according to their length and in that case, 400 finds 
the longest queue or the next full queue. In another em- 
bodiment, however, the amount of time that the queue 
has existed may also be taken into account. Another 
words, the longest queue would be sorted first unless 
that longest queue had not been processed for a speci- 
fied time such as X minutes. 

[0039] In a current queue at420, the message is found, 
removed from the queue and processed for delivery at 
420. A message wrapper is formed at 425, which may 
include multiple messages within the wrapper. Each of 
the messages within the wrapper has its own personal- 
ized content, but the common parts of the messages 
(such as the domain information) are provided by the 
wrapper itself. This may provide further streamlining of 
the process. 

[0040] Step 430 determines if there are more items 
with the queue that can go within the same wrapper, and 
if so, gets the message at 420 and adds it to the wrapper 
at 425. After the queue is finished, processing is carried 
out by 435 which shows locating an SMTP server for the 
recipientdomain, making a connection to the SMTP serv- 
er, sending protocol tokens representing the message, 
and then delivering the messages. 
[0041] Once all of the messages in the queue have 
been removed, then the queue is removed from the mem- 
ory map, or extinguished, at 445. If message processing 
fails due to a recoverable error, then the message may 
be pushed back into the queue, or into a new queue in- 
dicative of the same domain. Each time the message 
delivery fails, the "visit count" is incremented. Message 
failure may occur due to the recipient servers being un- 
available, e.g. busy or inaccessible. Processing then 
moves to the next queue at 450. 
[0042] An overflow prevention is shown in the flowchart 
of figure 5. Overflow may occur if messages are received 
faster than the queuing agent 225 can handle the mes- 



sages. At 500, the input handler detects that it has a 
backlog which is greater than a specified amount, for 
example, 1000 messages, or if the size of the message 
queue will take longer than a specified time to process, 

s such as 3 seconds. At 505 the input handler sends a 
"Pause" acknowledgment to the message server that is 
receiving the messages, e.g., the SMTP server. The 
pause acknowledgment indicates to the message server 
that it should stop sending messages that it has received. 

10 This causes the message server to save the received 
messages until the backlog is reduced. 
[0043] The loop continues to check the backlog at 500. 
If the number of messages in the queue has fallen below 
the size limit at 500, then the relay server sends a "send" 

15 acknowledgement to the message server at 510. This 
allows the message server to start sending messages 
again. 

[0044] The server application 702 may be able to trans- 
mit certain e-mail messages to certain domains quicker 

20 than others. In this case, the load balancer 732 may pass 
more e-mails for the faster domains to the server 702 
than it does for the slower domains. The statistics polling 
process 764 and listener processes may carry this out. 
In this way the message server effectively adjusts the 

25 feed rate according to the rate at which the relay servers 
are performing. This may allow the system to take into 
account slower relay servers, and prevent blocking of 
messages by slower relay servers. 
[0045] The basic load-balancing is made by the follow- 

30 ing steps: 

get the next message parameter; 
generate the full header and body with personaliza- 
tion; 

35 query the current load conditions and compute de- 
livery rates for the messages; 
compute whether the system relay is ready for new 
messages; and 
if so, push the messages. 

40 

[0046] In this way, the input handler receives the mes- 
sages only when it can handle the messages. This pro- 
vides one aspect of basic load balancing. 
[0047] Figure 6 shows a basic block diagram of the e- 

45 mail messaging system. A relay server 602 carries out 
the functions of handling the input messages. The relay 
server 602 includes a queuing agent 604, as well as a 
memory queue statistics element 606 and a message 
reactor 607. The message reactor 607 can be an SMTP 

50 server or a server that carries out comparable functions 
or a device that interfaces to an existing SMTP server. 
[0048] The message reactor 607 delivers the messag- 
es to the user mailboxes 608. Bounce server 606 detects 
any messages that are intended for mailboxes which do 

55 not exist, and "stores" those messages for further 
processing. 

[0049] An input parser 61 6 receives and characterizes 
the messages. Parser 616 includes a message server 
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610, statistics collector 612 and recovery agent 614. 
Each of these functions can be carried out in RAM or 
nonpersistent storage in order to facilitate the processing. 
The recovery agent stores snapshots of system variables 
to persistent storage, to allow the system to recover from 
a computer crash. In an alternative, although perhaps 
less preferred embodiment, however, queues or parts of 
queues can be maintained on a disk drive. The functions 
of these elements will be described in further detail here- 
in. 

[0050] Figure 7 is a flowchart of the passing of mes- 
sages between the client, server and license server au- 
thentication unit. 

[0051] The client application is shown as 700, and this 
may be for example, an e-mail client operating in a user's 
computer. The client application 700 creates personal- 
ized messages of a conventional type, and controls and 
commands sending those messages to the server. This 
is done using a number of agents; all of which may op- 
erate in software. 

[0052] In the client application 700, a number of differ- 
ent processes cooperate together in order to form and 
send an e-mail. A message files database 71 2 represents 
the specific message files which are being sent, that is, 
the text and/or attachments that form the unique parts of 
the e-mail. The other parts that may be used for many 
different e-mails, are stored in a file, such as databases 
710,714. A database 710 provides the e-mail addresses. 
Mailing preferences, including mailing information and 
the like for the recipient of the e-mail, are stored in the 
database 712. These two databases are used in con- 
junction with the mailing configuration file 714 that stores 
tracking information for the resulting e-mail. 
[0053] The nodes, such as 252 shown in figure 2, may 
be pointers to areas in the message file 71 2 and/or areas 
in the database 71 0 and configuration file 71 4. In addition, 
each e-mail may be assigned with a unique ID formed 
from a bit vector of the queued e-mail. The bit vector may 
be stored in persistent storage. The bit vector may include 
sufficient information to reconstruct the message and the 
state of processing of each of the e-mails. This informa- 
tion is stored on disk or persistent storage. This enables 
recovering the entire state of processing of the system, 
without storing the entirety of the e-mails to disk. 
[0054] Only certain data representing the contents of 
the e-mails, the locations in memory, and the tike are 
stored. For example, the message IDs of each of the 
messages in each of the queues may be recorded peri- 
odically in order to save the state. If the relay server goes 
down for any reason, then the IDs of the messages that 
were currently being processed are recorded. The crash 
is remedied by starting a new message server to transfer 
these non-processed messages to other relay servers in 
the set up. If all relay servers go down simultaneously, 
the undelivered message IDs remain recorded, and can 
be sent by the system. 

[0055] The e-mail address records in the database 71 0 
are processed by a database parser 720 along with the 



contents of the mailing configuration file 714. Corre- 
spondingly, the message records in the message data- 
base 712 are processed by a message parser 722. The 
two parsers 720 and 722 act on the database records 
s and pass parsed content to the personalization agent 

724. This agent combines the parsed information from 
the address record with the parsed message. In one em- 
bodiment, the parsed message may be formed by a mes- 
sage template, filled in with tokens from the message list 

10 parameters, for example the parameters that are shown 
in element 230 in figure 2. The personalized content such 
as the name or other information is inserted into the out- 
put messages based on the personalization. 
[0056] An e-mail message is created using the con- 

15 tents of the personalization agent 724 to create a mes- 
sage wrapper, which includes the message from the 
message parser 722 within the parsed address from the 
database parser 720 to create a personalized message 

725. The resulting address is preferably manipulated 
20 solely within random access memory to enable quicker 

handling. 

[0057] The personalized message 725 is then passed 
to a queuing agent 730 which takes the message input 
and queues it in the appropriate queues. The queues 

25 may be formed as described previously with reference 
to figure 2. The e-mail is generally queued according to 
the domain that will receive the e-mail. Often used do- 
main names may receive multiple queues. 
[0058] A client-to-server Load balancer 732 monitors 

30 the queues to ensure that the server 702 is not over- 
whelmed by incoming e-mails, as described above with 
reference to figure 5. 

[0059] The server application 702 uses request han- 
dler 740 to take the messages and deliver the messages 

35 to one or more delivery agents 742. While only one de- 
livery agent is shown, there may be many such agents. 
These delivery agents 742 communicate the e-mail mes- 
sages to a remote connection pool manager 744 that 
manages a number of remote connections. The remote 

40 connection pool manager 744 establishes, maintains and 
terminates connections with remove SMTP servers 
shown as 746, 780 and 782. 

[0060] The remote connection pool manager 744 may 
maintain the connections with the recipient SMTP serv- 
45 ers directly; taking the burden of doing this off of the 
SMTP server at the local ISP. 

[0061] The remote connection manager also uses 
asynchronous DNS resolvers 750 which operate from an 
off-line queue or cache 352 that is periodically updated. 

50 The DNS lookup may be asynchronous relative to the 
remaining parts of the message delivery. In this way, the 
lookup of DNS information at 750 from the DNS cache 
752 can be performed in parallel with other parts of the 
message delivery. 

55 [0062] The delivery agent or agents 342 are also in 
communication with the logging agent 760, which forms 
a monitor process to monitor which e-mails that have 
been sent. This may enable complete recovery in the 
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case of a system crash. 

[0063] The mailing configuration file 71 4, the database 
parser 720 and message parser 722 operate on a pre- 
dictable and logical basis. Therefore, by knowing where 
e-mail transmission was interrupted, the point that exist- 
ed at the time of any system crash can easily be recov- 
ered. 

[0064] The logging agent 760 also communicates with 
the statistics listener processes 762 and the statistics 
polling process 764. The logging agent 760 monitors suc- 
cessful and unsuccessful e-mail transmissions. Unsuc- 
cessful transmissions may occur when a remote server 
is unavailable or an unsuccessful DNS resolution occurs. 
The status polling process 764 is also in communication 
with the queuing agent 730 and maintains a record of the 
last outgoing message. In this way, an interrupted mail 
stream may be re-established at the point of interruption. 
[0065] The listener process 762 logs or provides infor- 
mation about successful e-mai! transmissions. In an em- 
bodiment, the information about e-mails, in the list, is 
listed by reference only. For example, the listener proc- 
ess 762 may indicate which can successfully delivered. 
This also maintains information or logs about rejected e- 
mails. The e-mails may be rejected in complete form, so 
that forensic analysis may be performed to determine 
how the failure arose. 

[0066] The logging agent 760 may also indicate when 
the e-mail was clicked on or opened. 
[0067] The logging agent collects and aggregates e- 
mail information from multiple sources may also be in 
contact with a license server statistics collector 770, and 
also in contact with a license server authentication proc- 
ess 704. The license server authentication is also in com- 
munication with both the server and client. 
[0068] The concept of license authentication is entirely 
a new paradigm according to the present system. The 
statistics collector 370 collect statistics about the number 
of messages that are processed by this system. In an 
embodiment, the server authentication 304 determines 
whether a user has paid appropriate license fees suffi- 
cient to cover the number/type of messages which have 
been sent. The server authentication 304 may refuse to 
send messages or may send warnings based on the 
number of messages having been exceeded. In this way, 
this software may operate effectively as pay-per-use soft- 
ware. That is, the initial software may be sold with some 
number of messages enabled. This may enable users to 
evaluate the software, almost as shareware, for a certain 
period of time. They may install it, and it will operate as 
desired until the specified number of messages is 
reached. After that, the user needs to pay additional li- 
cense fees to process additional messages. 
[0069] Although only a few embodiments have been 
described in detail above, other modifications are possi- 
ble. Many of the modifications are described herein. 
[0070] In an embodiment, the program features de- 
scribed above are written in C++ although it should be 
understood that other programs could be used to write 



this program, and also that the operations could be car- 
ried out using hardwired logic defined using hardware 
definition language, or FPGAs or other components. 
[0071] While this system is described in the context of 
5 use with e-mail applications, it can be used or any system 
that sends messages, preferably text messages, over a 
network such as the Internet. 

[0072] This system as embodied does not rely on third- 
party mail sending applications such as sendmail or other 
10 programs, although such can be used. 



Claims 

15 1. A method, comprising: 

processing a plurality of e-mails in an e-mail soft- 
ware package; 

maintaining a log representing a number of e- 
20 mails which have been processed in said soft- 

ware package; and 

comparing contents of said log with licensing in- 
formation, to determine if said number of e-mails 
which has been processed exceeds a number 
25 of e-mails which has been licensed. 

2. A method as in claim 1 further comprising: 

processing the plurality of e-mails solely within 
30 non persistent storage, without requiring that in- 

formation indicative of the e-mails be written to 
and then read from persistent storage during the 
processing of the plurality of e-mails. 

35 3. A method as in claim 2, further comprising storing, 
in persistent storage, recovery information indicative 
of the processing, said recovery information being 
used for recovery from a system fault. 

40 4. a method as in claim 3, wherein said recovery infor- 
mation includes information indicative of the plurality 
of e-mails, wherein said information is indicative of 
less than the entirety of each e-mail in said plurality 
of e-mails. 

45 

5. A method as in claim 1 , wherein said processing 
comprises: 

arranging information about the plurality of e- 
50 mails into a plurality of queues, each queue in 

the plurality of queues representing a single do- 
main in a plurality of single domains; and 
sending e-mails to a recipient, by sending a plu- 
rality of e-mails to a single domain in the plurality 
55 of single domains that a queue in the plurality of 

queues represents, at a specific sending in- 
stance. 



6 



11 



EP 1 715 640 A2 



12 



6. A method as in claim 5, wherein said sending com- 
prises: 

opening a communication channel to a single 
specified domain; and 

sending a plurality of e-mails within the commu- 
nication channel. 



7. A method as in claim 3, wherein said recovery infor- 
mation includes a number of said e-mails, and a state 10 
of processing of each e-mail in said number of e- 
mails. 



8. A method as in claim 5, further comprising: 

15 

selecting a first queue in said plurality of queues 
to be processed; and 

sending e-mails from the first queue all at once 
to the single domain that the first queue repre- 
sents. 20 



9. A method as in claim 8, wherein said first queue has 
the most e-mails within the queue. 

1 0. A method as in claim 8, wherein said first queue has 25 
existed for the greatest period of time. 

11. A method as in claim 8, further comprising, during 
said selecting, asynchronously looking up single do- 
main information for a second queue in said plurality 30 
of queues that is different than the first queue. 

12. A method as in claim 2, wherein said processing 
comprises: 

35 

determining a speed of processing of a single 
domain; and 

adjusting a speed of processing of the e-mails 
to said single domain based on said speed of 
processing of said single domain. 40 



1 3. A computer system, comprising: means for process- 
ing a plurality of e-mails in an e-mail software pack- 
age, means for maintaining a log representing a 
number of e-mails which have been processed in 45 
said software package, and means for comparing 
contents of said log with licensing information, to de- 
termine if said number of e-mails which has been 
processed exceeds a number of e-mails which has 
been licensed. 50 
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